src/main/resources/application.yml (1)

19-23: Hibernate 배치 설정 방향성은 좋습니다. MySQL 실제 배치 효율을 위해 드라이버 옵션도 함께 고려해 주세요.

• order_inserts, order_updates, hibernate.jdbc.batch_size, hibernate.jdbc.batch_versioned_data 설정 조합은 적절합니다.
• MySQL에서는 JDBC URL에 rewriteBatchedStatements=true를 포함하지 않으면 실제 네트워크 레벨 배치가 일어나지 않는 경우가 많습니다. 환경변수 SPRING_DATASOURCE_URL에 해당 옵션 포함 여부를 확인해 주세요. 예) jdbc:mysql://.../?rewriteBatchedStatements=true
• 배치 사이즈(현재 50)는 워크로드에 따라 50~200 사이 튜닝 여지가 큽니다. 모니터링 후 조정 권장.

src/main/java/project/flipnote/common/model/event/GroupJoinRequestedEvent.java (1)

5-10: 이벤트 불변성 강화를 위해 수신자 목록을 방어적 복사로 감싸는 것을 권장합니다.

Record라 해도 List<Long>는 가변이므로, 퍼블리셔/리스너 간 사이드 이펙트 방지를 위해 방어적 복사를 적용하면 안전합니다.

 public record GroupJoinRequestedEvent(
     Long groupId,
     List<Long> receiverIds,
     Long requesterId
 ) {
+    public GroupJoinRequestedEvent {
+        receiverIds = List.copyOf(receiverIds);
+    }
 }

src/main/java/project/flipnote/group/repository/GroupRolePermissionRepository.java (1)

3-18: 엔티티 대신 롤만 조회하는 경량 메서드 추가 제안

현재 메서드는 엔티티 전체를 로딩합니다. 호출부가 결국 GroupMemberRole 컬렉션만 필요하다면 롤만 select하는 전용 메서드가 불필요한 연관 로딩을 줄여줍니다.

아래처럼 쿼리 메서드를 추가하는 것을 고려해 주세요.

 import java.util.List;
+import org.springframework.data.jpa.repository.Query;
+import org.springframework.data.repository.query.Param;

 ...

     boolean existsByGroupAndRoleAndGroupPermission(Group group, GroupMemberRole role, GroupPermission groupPermission);

-    List<GroupRolePermission> findByGroupAndGroupPermission(Group group, GroupPermission groupPermission);
+    List<GroupRolePermission> findByGroupAndGroupPermission(Group group, GroupPermission groupPermission);
+
+    @Query("select grp.role from GroupRolePermission grp " +
+           "where grp.group = :group and grp.groupPermission = :perm")
+    List<GroupMemberRole> findRolesByGroupAndGroupPermission(@Param("group") Group group,
+                                                             @Param("perm") GroupPermission groupPermission);

• 장점
  • 불필요한 ManyToOne 로딩 회피
  • 호출부에서 곧바로 GroupMemberRepository.findByGroupAndRoleIn(...)에 전달 가능

src/main/java/project/flipnote/user/service/UserService.java (1)

127-130: 널 가드 및 활성 사용자 조회 조건 추가 검토

• Service 레이어 널 방어
  src/main/java/project/flipnote/user/service/UserService.java:127–130

  public String getNickname(Long userId) {
      if (userId == null) {
          throw new BizException(UserErrorCode.USER_NOT_FOUND);
      }
      return userProfileRepository.findNicknameById(userId)
          .orElseThrow(() -> new BizException(UserErrorCode.USER_NOT_FOUND));
  }

• 활성 사용자만 조회하도록 리포지토리 쿼리 수정
  src/main/java/project/flipnote/user/repository/UserProfileRepository.java:25–27

  // 기존
  @Query("SELECT up.nickname FROM UserProfile up WHERE up.id = :userId")
  Optional<String> findNicknameById(Long userId);
  
  // 제안: up.status = ACTIVE 조건 추가
  @Query("SELECT up.nickname FROM UserProfile up " +
         "WHERE up.id = :userId AND up.status = project.flipnote.user.entity.UserStatus.ACTIVE")
  Optional<String> findActiveNicknameById(Long userId);

  또는 메서드 명명 규칙 활용
  Optional<String> findNicknameByIdAndStatus(Long userId, UserStatus status);

• 캐싱 고려 (@Cacheable/@CacheEvict)
  알림 전파 경로 등 빈번하게 호출되는 경우 유효합니다.

src/main/java/project/flipnote/group/repository/GroupMemberRepository.java (1)

25-25: 알림 수신자 수집 시 ID만 조회하는 전용 메서드 추가 제안

현재는 GroupMember 엔티티 컬렉션을 로딩합니다. 수신자 ID만 필요하다면 사용자/그룹 연관 로딩 오버헤드를 줄이기 위해 ID 전용 조회를 권장합니다.

아래 메서드를 추가하면 불필요한 엔티티 로딩을 피할 수 있습니다.

 import java.util.List;
+import org.springframework.data.jpa.repository.Query;
+import org.springframework.data.repository.query.Param;

 ...

     List<GroupMember> findByGroupAndRoleIn(Group group, List<GroupMemberRole> roles);
+
+    @Query("select gm.user.id from GroupMember gm " +
+           "where gm.group = :group and gm.role in :roles")
+    List<Long> findUserIdsByGroupAndRoleIn(@Param("group") Group group,
+                                           @Param("roles") List<GroupMemberRole> roles);

• 장점
  • N+1 및 EAGER 연관 로딩 회피
  • 대량 알림 전파 경로에서 메모리 사용량 감소
• 참고: roles가 빈 리스트일 경우 호출부에서 조기 반환하면 불필요한 쿼리를 방지할 수 있습니다.

src/main/java/project/flipnote/notification/model/GroupJoinNotificationDispatchEvent.java (2)

7-10: 이벤트 내부 리스트를 불변으로 방어 복사하는 소폭 개선

퍼블리시 이후 외부에서 리스트를 변경할 여지를 제거하기 위해 방어 복사를 권장합니다.

아래처럼 compact constructor를 추가하면 됩니다:

 public record GroupJoinNotificationDispatchEvent(
 	List<Notification> notifications
 ) {
+	public GroupJoinNotificationDispatchEvent {
+		notifications = java.util.List.copyOf(notifications);
+	}
 }

---

7-10: 이벤트 페이로드에 JPA 엔티티 직접 전달: 현재 위험 없음
현재 Notification 엔티티는 지연 로딩 대상 연관관계가 없으므로, 비동기(@async) 리스너에서 전달된 엔티티를 그대로 사용해도 LazyInitializationException이 발생하지 않습니다.
다만, 이벤트 경계에서 영속성 컨텍스트 의존을 완전히 제거하려면 향후 다음과 같은 Optional 리팩토링을 고려할 수 있습니다:

• 변경 전

  public record GroupJoinNotificationDispatchEvent(
      List<Notification> notifications
  ) { }

• 변경 후 (Optional)

  public record GroupJoinNotificationDispatchEvent(
      List<Long> notificationIds
  ) { }

  • 호출부에서 ID 리스트로 이벤트 생성
  • 리스너에서 notificationRepository.findAllById(notificationIds) 등을 통해 엔티티 조회

src/main/java/project/flipnote/notification/repository/NotificationRepository.java (2)

24-34: 전체 일괄 읽음 처리 쿼리 변경은 합리적입니다. 파라미터 명을 receiverId로 통일하면 일관성이 좋아집니다.

• findNotificationsByReceiverIdAndCursor에서 receiverId를 사용 중이고, 엔티티 필드도 receiverId입니다. 본 메서드만 userId를 쓰고 있어 혼동 여지 있습니다. JPQL 바인딩 명도 함께 맞추는 것을 권장합니다.
• 성능 관점에서는 (receiver_id, is_read, id DESC) 조합 조회/업데이트가 많다면 DB 인덱스(복합)도 고려해 주세요. 특히 n.read = FALSE 조건과 receiverId 동시 조건이 빈번하면 효과가 큽니다.

적용 예시:

-       WHERE n.receiverId = :userId
+       WHERE n.receiverId = :receiverId
        AND n.read is FALSE

-int bulkMarkAsRead(
-    @Param("userId") Long userId,
-    @Param("now") LocalDateTime now
-);
+int bulkMarkAsRead(
+    @Param("receiverId") Long receiverId,
+    @Param("now") LocalDateTime now
+);

---

36-36: 소유권 검증용 조회 메서드 추가 적절합니다. 단건 읽음 처리 시 업데이트 쿼리도 고려해 보세요.

• Optional findByIdAndReceiverId(...)는 올바른 소유권 검증을 보장합니다.
• 추가로, 단건 읽음 처리에서 엔티티 로드 없이 즉시 업데이트하는 리포지토리 메서드도 유용할 수 있습니다(불필요한 SELECT 제거).

예시 제안(새 메서드 추가):

@Modifying(clearAutomatically = true, flushAutomatically = true)
@Query("""
    UPDATE Notification n
       SET n.read = TRUE, n.readAt = :now
     WHERE n.id = :id
       AND n.receiverId = :receiverId
       AND n.read = FALSE
""")
int markAsReadByIdAndReceiverId(@Param("id") Long id,
                                @Param("receiverId") Long receiverId,
                                @Param("now") LocalDateTime now);

src/main/java/project/flipnote/notification/entity/Notification.java (2)

36-36: DB 컬럼 명시로 명확성 향상 제안: groupId에 @column(name = "group_id") 추가

• 물리 네이밍 전략이 변경되거나 DDL 자동 생성이 아닌 경우를 대비해 컬럼명을 명시하는 편이 안전합니다.

적용 예시:

-    private Long groupId;
+    @Column(name = "group_id")
+    private Long groupId;

---

46-46: metadata 컬럼도 명시하면 이관/마이그레이션 시 혼선을 줄일 수 있습니다.

• 이전 필드(additionalData)에서 metadata로 변경되었습니다. 운영 DB에 컬럼명이 바뀌면 마이그레이션이 필요합니다. 코드에서도 컬럼명을 명시해 두면 의도가 분명합니다.

적용 예시:

-    @Convert(converter = MapToJsonConverter.class)
-    private Map<String, Object> metadata;
+    @Convert(converter = MapToJsonConverter.class)
+    @Column(name = "metadata")
+    private Map<String, Object> metadata;

src/main/java/project/flipnote/notification/controller/docs/NotificationControllerDocs.java (1)

25-30: Swagger 문서 정밀도 향상: PathVariable 어노테이션을 문서 인터페이스에도 추가 권장

• 구현체에는 @PathVariable이 있지만, 문서 인터페이스에도 추가하면 스키마 추출 시 파라미터 인식이 더 안정적입니다.

적용 예시:

-    @Operation(summary = "알림 읽음 처리")
-    ResponseEntity<Void> markNotificationAsRead(Long notificationId, AuthPrinciple authPrinciple);
+    @Operation(summary = "알림 읽음 처리")
+    ResponseEntity<Void> markNotificationAsRead(
+        @org.springframework.web.bind.annotation.PathVariable("notificationId") Long notificationId,
+        AuthPrinciple authPrinciple
+    );

또는 파일 상단에 import를 추가해 간결하게 표현할 수 있습니다(선택):

import org.springframework.web.bind.annotation.PathVariable;

src/main/java/project/flipnote/notification/listener/GroupJoinNotificationDispatchEventListener.java (1)

20-25: 전송 실패 내성 강화: @Retryable/@recover 추가 또는 재시도 전략 도입 제안

• 현재 서비스 레벨에서 try-catch로 로그만 남깁니다. 일시적 오류(네트워크 등)에 대한 재시도 정책이 없으면 손실될 수 있습니다.
• 다른 유사 리스너(GroupJoinRequestedEventListener, GroupInvitationCreateEventListener)와의 일관성 차이도 있습니다.

적용 예시:

     @Async
-    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
+    @org.springframework.retry.annotation.Retryable(
+        maxAttempts = 3,
+        backoff = @org.springframework.retry.annotation.Backoff(delay = 2000, multiplier = 2)
+    )
+    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
     public void handleGroupJoinNotificationDispatchEvent(GroupJoinNotificationDispatchEvent event) {
         notificationService.sendGroupJoinRequestNotifications(event.notifications());
     }
+
+    @org.springframework.retry.annotation.Recover
+    public void recover(Exception ex, GroupJoinNotificationDispatchEvent event) {
+        log.error("그룹 가입 알림 전송 디스패치 실패: notifications={}", event.notifications(), ex);
+    }

주의: 현재 NotificationService.sendGroupJoinRequestNotifications 내부에서 개별 알림 단위로 try-catch 하고 있어, 상단 @retryable이 동작하지 않을 수 있습니다. 재시도 전략을 활용하려면 서비스 레벨에서 예외 전파 방식도 정리해야 합니다.

src/main/java/project/flipnote/notification/controller/NotificationController.java (2)

52-59: API 응답 상태코드 204(No Content) 사용 권장

• 본 작업은 상태 변경성 엔드포인트로 본문이 없어 204가 더 적합합니다. 클라이언트 단 단순성도 증가합니다. (호환성 이슈 없으면 변경 추천)

적용 예시:

     @PostMapping("/read-all")
     public ResponseEntity<Void> markAllNotificationsAsRead(
         @AuthenticationPrincipal AuthPrinciple authPrinciple
     ) {
         notificationService.markAllNotificationsAsRead(authPrinciple.userId());

-        return ResponseEntity.ok().build();
+        return ResponseEntity.noContent().build();
     }

---

61-68: 단건 읽음 처리 응답 코드 204(No Content)로 통일 제안

• 반환 코드를 ResponseEntity.noContent()(204)로 변경하여 일관성 유지 권장
• GlobalExceptionHandler의 @ExceptionHandler(BizException.class)가
  exception.getErrorCode().getStatus() 기반으로 404/403 등 적절히 매핑함을 확인했습니다

적용 예시:

     @PostMapping("/{notificationId}/read")
     public ResponseEntity<Void> markNotificationAsRead(
         @PathVariable("notificationId") Long notificationId,
         @AuthenticationPrincipal AuthPrinciple authPrinciple
     ) {
         notificationService.markNotificationAsRead(authPrinciple.userId(), notificationId);

-        return ResponseEntity.ok().build();
+        return ResponseEntity.noContent().build();
     }

src/main/java/project/flipnote/notification/model/NotificationResponse.java (1)

12-15: API 스키마 변경(groupId/metadata)으로 인한 호환성 영향 점검 필요

응답 레코드에 groupId 추가 및 additionalData→metadata로 변경되었습니다. 클라이언트/문서/스냅샷 테스트가 이 변경을 수용하는지 확인하세요. groupId/readAt가 null일 수 있다면 직렬화 정책도 점검이 필요합니다.

권장(선택): null 필드 숨김을 위해 레코드에 JsonInclude 추가를 제안드립니다.

-import com.fasterxml.jackson.annotation.JsonFormat;
+import com.fasterxml.jackson.annotation.JsonFormat;
+import com.fasterxml.jackson.annotation.JsonInclude;
@@
-public record NotificationResponse(
+@JsonInclude(JsonInclude.Include.NON_NULL)
+public record NotificationResponse(

src/main/java/project/flipnote/groupjoin/service/GroupJoinService.java (2)

160-167: 권한-역할 조회 최적화(TODO 반영 제안)

GroupPermission 엔티티 조회 없이 enum 자체를 키로 사용하는 구조(캐시 또는 자연키)를 도입하면 쿼리를 줄일 수 있습니다. 권한 테이블이 적고 변경이 드문 점을 고려해 간단한 @Cacheable 캐싱도 효과적입니다.

원하시면 Permission 캐시 적용(예: Caffeine/스프링 캐시) 패치를 제안드리겠습니다.

---

168-173: 중복/자기 자신 제외 처리 제안

관리 권한을 가진 신청자가 존재할 수도 있어 자기 자신이 수신자에 포함될 수 있습니다. 중복/본인 제외를 권장합니다.

-        List<Long> receiverIds = groupMemberRepository.findByGroupAndRoleIn(group, memberRoles)
-            .stream()
-            .map(gm -> gm.getUser().getId())
-            .toList();
+        List<Long> receiverIds = groupMemberRepository.findByGroupAndRoleIn(group, memberRoles)
+            .stream()
+            .map(gm -> gm.getUser().getId())
+            .filter(id -> !id.equals(requester.getId()))
+            .distinct()
+            .toList();

src/main/java/project/flipnote/notification/listener/GroupJoinRequestedEventListener.java (1)

33-39: 재시도-멱등성 관점 점검 권장

리스너 재시도 시 NotificationService 레벨에서 멱등성 보장이 없으면 중복 전송 가능성이 있습니다(예: 동일 이벤트 재처리). 자연키 기반 중복 방지나 전송 로그를 고려해보세요.

멱등성 장치가 이미 있다면 공유 부탁드립니다. 필요 시 중복 방지 키 전략 설계를 도와드릴 수 있습니다.

src/main/java/project/flipnote/notification/service/NotificationService.java (2)

178-191: 전송 메서드 트랜잭션 경계 재검토

sendGroupJoinRequestNotifications는 @transactional이 없어 내부에서 호출하는 sendNotification의 토큰 삭제/업데이트가 개별 오토커밋으로 실행됩니다. 현재 요구사항에 따라 문제는 없을 수 있으나, 클래스 주석(“반드시 트랜잭션 적용된 public 메서드에서 호출”)과 불일치합니다.

선택지:

• 간단: 주석을 실제 동작에 맞게 정정.
• 일관성: 본 메서드에 @transactional(readOnly = false)을 부여해 토큰 정리 로직을 하나의 트랜잭션으로 묶기.

---

222-261: 토큰 정리 로직은 합리적이나 buildMessage/variables NPE 가능성 대비 권장

Firebase 에러 매핑/불량 토큰 정리는 적절합니다. 다만 variables가 null인 알림 타입이 생길 경우 StringSubstitutor에서 NPE가 날 수 있습니다.

아래처럼 NPE를 방어하면 안전합니다.

-        StringSubstitutor substitutor = new StringSubstitutor(notification.getVariables());
+        StringSubstitutor substitutor = new StringSubstitutor(
+            notification.getVariables() != null ? notification.getVariables() : Map.of()
+        );

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

src/main/java/project/flipnote/notification/service/NotificationService.java (1)

119-134: FCM 토큰 재할당 누락: 다른 사용자 소유 토큰 삭제 후 재저장이 필요합니다

기존 토큰이 다른 사용자에게 매핑되어 있으면 삭제만 하고 현재 사용자에 대한 재저장이 이뤄지지 않습니다. 결과적으로 토큰이 미등록 상태가 됩니다.

아래 패치로 삭제 후 재등록을 보완해 주세요.

  public void registerFcmToken(Long userId, TokenRegisterRequest req) {
      Optional<FcmToken> existingToken = fcmTokenRepository.findByToken(req.token());

      if (existingToken.isPresent()) {
          FcmToken token = existingToken.get();

          if (Objects.equals(token.getUserId(), userId)) {
              token.updateLastUsedAt();
          } else {
              fcmTokenRepository.deleteById(token.getId());
+             // 동일 토큰을 현재 사용자에게 재할당
+             saveFcmToken(userId, req.token());
          }
      } else {
          saveFcmToken(userId, req.token());
      }
  }

src/main/java/project/flipnote/common/model/request/CursorPageRequest.java (1)

21-37: 비정상 커서 값을 무음(null) 처리할지, 400(Bad Request)로 명확히 실패시킬지 정책 합의가 필요합니다

현재는 "abc", "1e10", "99999999999999999999" 같은 입력을 모두 null로 간주하여 첫 페이지를 반환합니다. 클라이언트 디버깅/오류 탐지 측면에선 명시적 검증이 더 유리합니다.

가능한 개선안:

• 검증 어노테이션으로 유효성 선제 차단: cursor에 @Pattern(regexp = "\\s*\\d+\\s*") 적용해 숫자만 허용
• 음수/0 커서는 무효 처리: parse 이후 <= 0이면 null 반환
• API 정책상 잘못된 커서는 400으로 응답하도록 컨트롤러 레이어에서 바인딩 에러 처리

원하시면 위 정책에 맞춘 변경 패치를 제안드리겠습니다.

src/main/java/project/flipnote/notification/model/NotificationListRequest.java (1)

8-16: 문서화 보강: 스웨거 스키마/예시 추가를 권장합니다

API 소비자 경험을 위해 필터 의미와 예시 값을 명시하면 좋습니다.

예시:

• groupId: 특정 그룹의 알림만 조회 (예: 123)
• read: 읽음 여부 필터 (예: true면 읽은 알림만)
  원하시면 @Schema(description = "...", example = "...") 추가 패치 드리겠습니다.

src/main/java/project/flipnote/notification/repository/NotificationRepository.java (1)

17-30: 대량 조회 성능 최적화 제안: 인덱스 확인

조건절이 receiverId (AND id < cursor) 중심이므로 아래 인덱스 고려를 권합니다.

• 복합 인덱스: (receiver_id, id DESC) — 커서 조건과 정렬 동시 활용
• 추가 필터 사용 빈도에 따라: (receiver_id, group_id, is_read, id DESC)
  인덱스 전략은 실제 질의 빈도/카디널리티 기반으로 최적화가 필요합니다.

src/main/java/project/flipnote/notification/service/NotificationService.java (1)

100-110: 그룹 초대 알림 전송의 트랜잭션 롤백 전파 주의

sendNotification 실패 시 BizException을 던져 알림 저장까지 롤백될 수 있습니다. 그룹 가입 신청 쪽은 이벤트 기반 비동기로 전송을 분리했는데, 초대 역시 동일한 패턴으로 일관화하는 것을 권장합니다.

대안:

• 알림 엔티티 저장은 커밋 보장, 전송은 이벤트 리스너(@Async/@TransactionalEventListener)로 위임
• 혹은 전송 실패를 로깅 후 삼키고 재처리 큐 도입
  원하시면 초대 전송 흐름도 이벤트 기반으로 리팩터 제안 드리겠습니다.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

src/main/java/project/flipnote/groupjoin/service/GroupJoinService.java (2)

170-176: 알림 수신자 ID 매핑 오류: 그룹 ID를 수신자 ID로 사용 중

알림 수신자 ID를 groupMember.getGroup().getId()로 매핑하고 있어, 실제 유저 ID가 아닌 그룹 ID가 전달됩니다. NotificationService는 수신자(userId) 기준으로 동작하므로 전송 실패/오발송의 원인이 됩니다. 유저 ID로 매핑하세요.

적용 diff:

-        List<Long> receiverIds = groupMemberRepository.findByGroupAndRoleIn(group, memberRoles)
-            .stream()
-            .map((groupMember ->  groupMember.getGroup().getId()))
-            .toList();
+        List<Long> receiverIds = groupMemberRepository.findByGroupAndRoleIn(group, memberRoles)
+            .stream()
+            .map(gm -> gm.getUser().getId())
+            .toList();

---

147-151: 자동 가입(applicationRequired=false) 시 그룹 멤버 추가 누락

applicationRequired=false인 경우 status=ACCEPT로 저장되지만 실제 GroupMember 추가가 없습니다. 자동 가입 시에는 즉시 멤버를 추가해야 일관성이 맞습니다. (이전 리뷰 코멘트와 동일 이슈)

적용 diff:

-        if (group.getApplicationRequired()) {
-            sendJoinRequestNotification(group, user);
-        }
+        if (group.getApplicationRequired()) {
+            sendJoinRequestNotification(group, user);
+        } else {
+            // 자동 가입: 그룹 멤버 즉시 추가
+            GroupMember groupMember = GroupMember.builder()
+                .group(group)
+                .user(user)
+                .role(GroupMemberRole.MEMBER)
+                .build();
+            groupMemberRepository.save(groupMember);
+        }

src/main/java/project/flipnote/groupjoin/service/GroupJoinService.java (3)

129-131: 최대 인원 선검사 위치 개선 제안

대기(PENDING) 플로우에서도 선제적으로 인원 제한을 검사하면, 현재 만석일 때 신청 자체가 불가능합니다. 일반적으로 인원 검사는 승인 시점에만 필요합니다. 자동 가입일 때만 선 검사로 제한하는 것을 권장합니다.

적용 diff:

-        //그룹이 최대인원인 경우
-        checkMaxMember(group);
+        // 그룹이 최대인원인 경우(자동 가입 시에만 선 체크)
+        if (!group.getApplicationRequired()) {
+            checkMaxMember(group);
+        }

---

230-238: 중복 멤버 추가 방지(멱등성)

승인 처리 시 이미 가입된 유저를 다시 추가하면 데이터 무결성 오류(중복 키) 가능성이 있습니다. 저장 전에 존재 여부를 확인해 멱등하게 처리하는 것을 권장합니다.

적용 diff:

-            groupMemberRepository.save(groupMember);
+            if (groupMemberRepository.findByGroupAndUser(group, groupJoin.getUser()).isEmpty()) {
+                groupMemberRepository.save(groupMember);
+            }

추가로, 자동 가입 경로에서도 동일한 체크를 적용하면 더 안전합니다.

---

68-71: 중복 가입신청 판정 로직 개선 제안

existsByGroup_idAndUser_id는 신청 상태와 무관하게 존재만 보면 true를 반환합니다. REJECT/CANCEL 이후 재신청을 허용하려면 상태 조건(PENDING/ACCEPT 등)에 한정하거나, 비즈니스 요구에 맞는 상태 기반 exists 쿼리를 도입하는 것이 좋습니다.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

src/main/java/project/flipnote/notification/service/NotificationService.java (1)

121-134: 다른 사용자 소유의 FCM 토큰 재등록 시 저장 누락 버그

기존 토큰이 타 사용자 소유인 경우, 삭제만 수행하고 현재 사용자로 재등록을 하지 않아 최종적으로 토큰이 사라집니다. 삭제 후 즉시 현재 사용자로 저장이 필요합니다.

다음 수정안을 적용해 주세요:

   if (existingToken.isPresent()) {
     FcmToken token = existingToken.get();

     if (Objects.equals(token.getUserId(), userId)) {
       token.updateLastUsedAt();
     } else {
-      fcmTokenRepository.deleteById(token.getId());
+      fcmTokenRepository.deleteById(token.getId());
+      // 동일 물리 토큰을 현재 사용자로 재등록
+      saveFcmToken(userId, req.token());
     }
   } else {
     saveFcmToken(userId, req.token());
   }

src/main/java/project/flipnote/notification/service/NotificationService.java (3)

156-172: 수신자 리스트 전처리(중복/자기 자신 제외/널 가드) 권장

실수로 동일 ID가 중복되거나 신청자가 자기 자신을 포함시키는 경우를 방지하세요. 또한 널 안전성 확보를 권장합니다.

아래처럼 스트림 전처리를 추가해 주세요:

- List<Notification> notifications = receiverIds.stream()
-   .map((receiverId) -> Notification.builder()
+ List<Notification> notifications = receiverIds.stream()
+   .filter(Objects::nonNull)
+   .filter(receiverId -> !Objects.equals(receiverId, requesterId))
+   .distinct()
+   .map(receiverId -> Notification.builder()
      .receiverId(receiverId)
      .groupId(groupId)
      .type(type)
      .variables(Map.of("requesterNickname", requesterNickname))
      .metadata(Map.of("requesterId", requesterId))
      .build())
   .toList();

---

180-193: 전송 실패 처리 전략 고도화 제안

현재는 try/catch + 로그만 존재합니다. 운영 신뢰성을 위해 다음을 고려해 주세요.

• 이벤트 리스너(@async + @retryable)로 재시도(지수 백오프) 처리
• 실패 건을 DLQ/아웃박스 테이블에 적재 후 배치 재전송
• 사용자별 토큰 갱신/삭제는 이미 적용되어 좋습니다

원하시면 간단한 아웃박스 엔티티/스케줄러 설계를 제안드리겠습니다.

---

238-243: 개별 응답의 예외 null 가드 추가 제안

Firebase SDK에서 실패 응답은 보통 예외가 있으나, 방어적으로 null 가드를 추가해 NPE를 예방하는 것이 안전합니다.

- String errorName = res.getException().getMessagingErrorCode().name();
+ String errorName = (res.getException() != null && res.getException().getMessagingErrorCode() != null)
+   ? res.getException().getMessagingErrorCode().name()
+   : "INTERNAL";

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.